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(54) Web application development system 

(57) It is demanded to add a new service to the Web 
quickly and to develop a Web application system in a 
short period of time to extend a service. It is thus nec- 
essary to alleviate the burden on developers or pro- 
grammers to speed up development, and to cope with 
complicated systems or to make systems extensible. 
Thus, the system has to be designed to clearly associate 
components with one another and separate their re- 
spective roles. In the development of a Web application 
system, each of the components of the servlet, JSP, and 



Bean is defined in a one-to-one relationship correspond- 
ing to each screen image, thereby making the relation- 
ship among each of the components clear. A component 
table generating unit is provided for generating the def- 
inition of each component as a component table from 
screen design. Also provided is an automatic code gen- 
erating unit for automatically generating the code of 
servlet, JSP, and Bean using the component table and 
the information of the design document. This facilitates 
the development and alleviates the burden on develop- 
ers or programmers. 
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Description 

BACKGROUND OF THE INVENTION 

1. FIELD OF THE INVENTION 

[0001] The present Invention relates to a method for 
developing a Web application and io a development 
support system. More particularly, it relates to a support 
technology for deigning and developing a servlet, JSP, 
and JavaBeans component (Bean) In a Web application 
system which employs the server-side Java technology. 

2. DETAILED DESCRIPTION OF THE PRIOR ARTS 

[0002] Recently, In a Web application system on the 
Inter- and Intranet, such a system has come into wide- 
spread use that makes use of the server-side Java tech- 
nology, conventional woo systems typically employ 
CGI (Common Gateway Interface) programs. However, 
servlets are substituting for the CGI to become main- 
stream in the development of systems. The servJet pro- 
vides the functionality similar to tho CGI and is a servor- 
sideprogram forexecuting on aserverfora request sent 
from a client (Web browser) and then sending back the 
resulting data to the client, 

[0003] It is the most basic that the servlet Is used as 
follows. The servlet is activated according to a request 
sent from a Web browser to gain access to a database, 
receive, and then process the resulting data, in addition, 
the servlet performs branched processing or calls other 
servlets according to the contents of the request to send 
back the resulting data to the Web browser. In some cas- 
ee, JSP's (JavaServer Pages) aro omployod inaiead of 
the servlet The JSP technology is a major extension to 
write Java codes into HTML file and can be combined 
with the servlet to be used together 
[00O4] In a conventional system configured by em- 
ploying the servlet, JSP, and Bean, the Bean accesses 
databases as well as performs business transactions, 
also acts to hold the resulting data. Designing and de- 
veloping the Bean used to require knowledge and ex- 
perience on Java more man trie development of the JSP. 
In addition, In the conventional development, each com- 
ponent was shared on the server aide to develop sepa- 
rately a servlet, JSP and Bean that is utilized by them. 
Thus, as can be seen in the waterfall development, it 
was necessary to clearly define the target of develop- 
ment in advance. 

[0005] In recent system developments, the develop- 
ment cycle time has been increasingly made shorter. In 
particular to make a business system or a business 
service public on the Web, customers require strongly 
to make the development cycle time shorter. Thus, in a 
Web application system, it is required not only to peri- 
odically update the design or information of Web pages 
but also to make a new service public as soon as pos- 
sible on the system or quickly extend me service, tnat 



Is, to complete development in a shorter period of time. 
To cope with these customer needs as well as a shorter 
development cycle time for Web application systems, it 
is necessary to alleviate the burden on developers or 
* programmers and provide a significant speedup in the 
development. 

[0006] Furthermore, the conventional development 
method allowed the servlet and JSP to perform process- 
ing according to a request and then describe a program 

10 for oroaxing a eoreen In aooordano* with the resulting 
data. Accordingly, this caused ihe system to become 
larger, and made it necessary for Individual developer 
to have wider knowledge on Java as the system and 
programming became more complicated, and collect 

*s Java programs for the development. The developers or 
programmers were further burdened with understand- 
ing the processing performed by the servlet or JSP to 
be developed, coding, debugging, and maintenance 
thereof. 

so [0007] When each servlet and Bean employed by the 
servlet were independently developed, they could not 
be combined together to chock the overall operation un- 
til developers provided thelrclaseea. On the other hand, 
when the servlet and Bean are independently devef- 
55 oped, it Is Impossible to achieve commonality since the 
developers develop a servlet, JSP, and Bean Independ- 
ently of one another This made the development de- 
pendent on the skill of each developer and the mainte- 
nance difficult to be carried out. 

30 

SUMMARY OF THE INVENTION 

[0008] Th e present invention was developed to solve 
the aforementioned problems. That le, an objeot of the 

3 $ present invention is to alleviate the burden on develop- 
ers or programmers who design and develop a aerviet, 
JSP, Bean In a Web application system that employs the 
server-side Java technology, thereby providing a spee- 
dup in the design and development. 

40 [0009] To achieve the aforementioned object, a first 
aspect of the present invention provides a Web applica- 
tion development method for developing, on the Inter- 
and intranet, a web application system having server- 
side Java technologies such as a servlet, JSP, and Java- 

* G Beano component (Bean). The method is characterized 
In that in accordance with a GUI specification provided 
by a design specification for said Web application sys- 
tem, a source filename of each component of the serv- 
let JSP, and Bean is defined corresponding to each 

5° screen image to develop the servlet, JSP, and Bean. 
[0010] A second aspect of the present Invention is a 
Web application development method for developing, 
on the Inter- and Intranet, a Web application system 
having server-side Java technologies such as a servlet, 

■55 JSP, and JavaBearts component (Bean), The method Is 
characterized in that in accordance with a GUI specifi- 
cation provided by a design specification for said Web 
application system, a source niename or each compo- 
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nent of Che servlet. JSP, and Bean is defined in a one- 
to-one relationship corresponding to each screen image 
to develop the servlei, JSP, and Bean. 
[0011] A third aspect of the present invention is char- 
acterized in char, in the first or second aspect, a source 
cocre or each component Is auromailcally generated us- 
ing the relationship between said screen and a source 
filename of each component of said servlet, JSP, and 
Bean, and information of said design specification. 
[001 2] A fourth aspect of the present invention ic char- 
acterized in that, In the first or second aspect, said Bean 
component is provided with all pieces of information 
necessary for displaying an HTML page, and serves to 
carry out mapping information of an HTML page and in- 
formation to be retrieved from a database. 
[0013] A fifth aspect of the present invention is char- 
acterized in that, in the third aspect, upon generation of 
the source code of each component of said servlet. JSP, 
and Bean, a template list is displayed Tor each compo- 
nent to be generated, a template selected from the tem- 
plate list Is employed as a model, and a code is written 
to the model in accordance with said design specifica- 
tion to automatically generate a source code. 
[001 4) A sixth aspect of the present invention is a Web 
application development method for developing, on the 
Inter- and Intranet, a Web application system having 
server-side Java technologies such as a servlet, JSP, 
and JavaBeans component (Bean). The method is char- 
acterized by comprising the step of reading a GUI spec- 
ification provided by a design specification to generate 
each component name of a servlet, JSP, and/or Bean 
corresponding to a screen name Tor eacn screen. Tne 
method also comprises the step of selecting a template 
from a template Wet with reaped to each component of 
a generated name, the template being a model of a 
source file of the component. The method further com- 
prises the step of generating automatically a source 
code of the component by writing the code to said tem- 
plate In accordance with a design specification of the 
component. 

[0015] A seventh aspect of the present invention Is 
characterized In that, In the sixth aspect, said template 
list includes a superclass template, and the step of gen- 
erating automatically said source code is to Inherit said 
superclass ;o create eald aource code. 
[0016] An eighth aspect of the present Invention is 
characterized In that, in the sixth aspect, said step of 
generating a name of each componeni is to generate a 
name of each component of a servlet, JSP, and/or Been 
in a one-to-one relationship with a screen name for said 
each screen. 

[0017] A ninth aspect of the present invention is char- 
acterized in that, in any of (he first - eighth aspects, in a 
Web application system to be developed, the servlet 
serves to receive a request from a Web browser; the 
Bean serves to perform processing In accordance with 
the request of the servlet to hold resulting data; and the 
JSP serves to retrieve the resulting data oT the Bean to 



generate an HTML displayed on the Web browser. Thus, 
each role of the servlet, JSP, and Bean is separated from 
each other, 

[0018] A tenth aspect of the present invention is a pro- 
5 gram provided by a method for developing a Web appli- 
cation according to any one of tne foregoing aspects, 
[0019] An eleventh aspect of the present invention 13 
a storage medium for storing a program provided by a 
method for developing a Web application according to 
10 any on© of the fket to the ninth aepeote. 

[0020] A twelfth aspect of the present invention is a 
Web application development system for developing, on 
the Inter- and Intranet, a Web application system having 
server-side Java technologies such as a servlet, JSP, 

19 and JavaBeans component (Bean). The system is char- 
acterized by comprising means for developing the serv- 
let, JSP, and Bean by defining a source filename of each 
component of the servlet, JSP, and Bean corresponding 
to each screen image, in accordance with a GUI specl- 

20 flcatlon provided by a design specification for said Web 
application system. 

[0021] A thirteenth aspect of the present invention is 
e Web application development system for developing, 
on the Inter- and Intranet, a Web application system 
having server-side Java technologies such as a servlet, 
JSP, and JavaBeans component (Bean) . The system Is 
characterized by comprising means for developing the 
servlet, JSP, and Bean by defining a source filename of 
each component of the servlet, JSP, and Bean in a one- 

30 to-one relationship corresponding to each screen im- 
age, in accordance with a GUI specif bation provided by 
a design specification Tor said web application system. 
[0022] A fourteenth aspect of the present invention is 
ohanaoterlzed In that, in the twelfth or thirteenth aspect, 

35 by further comprising means for automatically generat- 
ing a source code of each component, using tho rela- 
tionship between said screen and a source filename of 
each component of said servlet. JSP, and Bean, and in- 
formation of said design specification . 

*o [0023] A fifteenth aspect of the present invention is 
characterized In that, in the twelfth or thirteenth aspect, 
said Bean component is provided with all pieces of In- 
formation necessary for displaying an HTML page, and 
serves to carry out mapping information of an HTML 

+s page and information to be retrieved from a database. 
[0024] A sixteenth aspect of the present invention is 
characterized in that, in the fourteenth aspect, by further 
comprising, upon generation of the source code of each 

component of said servlet, JSP, and Bean, means for 

90 displaying a template list for each component to be gen- 
erated, for employing a template selected from the tem- 
plate list as a model, and for writing a code to the model 
in accordance with said design specification to automat- 
ically generate a source code. 

55 [0025] A seventeenth aspect of the present invention 
is a Web application development system for develop- 
ing, on the Inter- and intranet, a Web application system 
having server-side Java technologies such as a servlet, 
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JSP t and JavaBeans component (Bean) . The system is 
characterized by comprising moans for reading a QUI 
specification provided by a design specification to gen- 
erate each component name of a servlet, JSP, and/or 
Bean corresponding to a screen name for each screen , 5 
The system is also characterized by comprising means 
for selecting a template from a template list with respect 
to each component of b generated name, the template 
being a model of a source file of the component. The 
system is also characterized by comprising moans for 10 
generating automatically a source code of the compo- 
nent by writing the code To said template in accordance 
with a design specification of the component. 
[0026] An eighteenth aspect of the present invention 
Is characterized In that, In The seventeenth aspect, said fs 
template list includes a superclass template, and the 
means for generating automatically said source code 
are to inherit said superclass to create said source code. 
£0027] A nineteenth aspect of the present invention is 
characterized in that, In the seventeenth aspect, said 2a 
means for generating a name of each component is to 
generate a name of each component of a servlet, JSP, 
and/or Bean in a one-to-one relationship with a screen 
name for said each screen. 

[0028] A twentieth aspect of the present invention is 25 
characterized in that, in any one of the twelfth to nine- 
teenth aspects, in a Web application system to be de- 
veloped, the servlet serves to receive a request from a 
Web browser; the Bean serves to perform processing in 
accordance with the request of the sen/let to hold result- 30 
Ing data; and the JSP serves to retrieve the resulting 
data of the Bean to generate an HTML displayed on the 
Web browser. Thus, each role of the servlet, JSP, and 
Boan ifi coparatod from oach other, 

[0029] ThaL is the present inveniion is characterized 3$ 
by comprising a component table for defining in list form 
the source filename of each component of the servlet, 
JSP, and Bean in a one-to-one relationship correspond- 
ing to each screen image of the GUI specification pro- 
vided by a design document. The invention is also char- *o 
acterized by comprising an automatic code generating 
unit for automatically extracting and generating, as a 
source code, me name, variable, ana rneinoa definition 
of each component of the servlet, JSP, and Bean, and 

the ©all relationship among the components by making *f 

use of the information of the component table and the 
design document. Template data that includes a code 
or template of each component, used upon generation 
of source codes In the automatic code generating unit, 
is stored In a predetermined external storage unit. Also so 
stored therein are source codes or servlet superclasses 
and source codes of each component generated. 
[0030] As described above, in the development of a 
Web application system, the source filename of each 
component of the servlet, JSP, and Bean is defined in a & 
one-to-one relationship corresponding to each screen 
image. This makes it possible to clarify the relationship 
between each of the components, Furthermore, each 



screen can be developed independently by standardiz- 
ing the processing of the servlet, JSP, and Bean. 
[0031] Furthermore, the relationship between each of 
the components is made clear for each screen and their 
respective roles are designed to be separate from each 
otner r tnereoy ma King tt possible to cope readiry wftn a 
complicated system or extend easily the function of the 
system. Use of the server-aide Java technology would 
make it possible to separate the roles of the servlet, JSP, 
end Bean from each other in a man nor cuch that tho 
servlet serves to receive a request from a Web browser; 
the Bean serves to perform processing in accordance 
with the request of the servlet to hold resulting data; and 
the JS P serves to retrieve the resulting data of the Bean 
to generate an HTML displayed on the Web browser. In 
particular, the inveniion is characterized In that the Bean 
is designed to have ail pieces of information necessary 
for displaying an HTML page using the resulting classes 
provided by the analysis and design of business rules 
or classes for accessing a database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0032] Fig. 1 is a view depicting an example of a com- 
ponent table representative of the relationship among 
the screen, the servlet, JSP, and Bean of a Web appli- 
cation system to be developed. 
[0033] Fig.2 is a view depicting an example of the con- 
figuration of a system according to an embodiment. 
[0034] Fig,3 is a view depicting an example of the 
overall configuration of a Web application system which 
employs tne servlet, JSP, and Bean. 
[0035] Flg.4 Is a view depicting an example of a flow- 
chart for gonorating a component table. 

[0036] Fig .5 is a view depicting an example of a flow- 
chart for automatically generating a source code. 
[0037] Fig. 6 is a view depicting an example of a flow- 
chart for automatically generating a sen/let source code. 
[0038] Fig. 7 is an explanatory view depicting a flow 
for generating a servlet source code. 
[0039] Fig.s is a view depicting an example of a serv- 
let superclass source code. 

[004O] Fig. 9 is a view depicting an example of a flow- 
chart for automatically generating a JSP source code. 
[0041] FI9, 1 0 *9 an explanatory view depicting a Row 
for generating a JSP source code. 
[0042] Fig. 11 Is a view depicting an example of a flow- 
chart for automatically generating a Bean source code, 
[0043] Fig. 1 2 is an explanatory view deplciino a flow 
for generating a Bean source code. 
[0044] Fig. 13 is a view depicting the relationship be- 
tween screen information and Bean. 
[0045] Fig. 14 is a view depicting the overall configu- 
ration of a Web application system which employs the 
servlet, JSP, and Bean, according to a second embod- 
iment. 

[0046] Fig. 1 5 depicts the relationship between the re- 
cipient component and the response component, which 
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are employed in a Web application system according to 
the second embodiment. 

[0047] Fig.16 is a view depicting a (first) example of 
defining a one-to-one relationship between the recipient 
and response components, 

[004&] Rg.1 r Is a view depicting a (second) example 
of defining a one-to-one relationship between the recip- 
ient and response components 
[0049] Fig,18 is a view depleting a (first) example of 
a component definition tab I© of components. 
[0050] Fig. 1 9 is a view depicting a (second) example 
of a component definition table of components. 
[0051] Fig. 20 is a view depicting an example of the 
configuration of a system for designing and developing 
a Web application system. 

[0052] Fig.21 is a view depicting an example of a de- 
velopment procedure for designing and developing a 
Web application system. 

[0093] Flg.zz is a flowchart depicting a flow Tor gen- 
erating a component definition table. 
[0054] Rg.23 is a flowchart depicting a flow for auto- 
matically generating a source code. 
[0055] Fig. 24 is a flowchart depicting a flow for auto- 
matically generating a serviet source code. 
[0056] Fig.25 is a view depicting a (first) example of 
generating a serviet source code. 
[0057] Flg,26 Is a view depicting a (second) example 
of generating a serviet source code. 
[0058] Fig .27 is a view depicting an example of a serv- 
iet superclass code. 

[0059] Fig.28 is a view depicting a (first) Image of se- 
lecting a template. 

[0060] Fig. 29 is a view depicting a (second) image of 
co looting aromplaio. 

[0061] Flg.30 is a flowchart depicting a flow for auto- 
matically generating a Bean source code. 
[0062] Fig.31 is a view depicting an example of gen- 
erating a Bean source code. 

[0063] Rg.32 is a view depicting the relationship be- 
tween screen information and Bean. 
[0064] Flg.33 Is a flowchart depicting a flow for auto- 
matically generating a JSP source code. 
£0065] Fig.34 is a view depicting an example oT gen- 
erating a JSP source code. 

[0066] Rg.35 i« o view depicting an image of editing 
a source code. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0067] Now, embodiments of the present Invention 
are explained specif icaliy wfth reference to the accom- 
panying drawings. 

[0066] A first embodiment according to the present in- 
vention is explained below. Here, such an example is 
explained in which a Web application system employing 
the serviet, JSP, and Bean, described later with refer- 
ence to Fig. 3, is designed and developed. In particular. 



the present Invention is characterized in thatthe source 
file name of each of the components OT the serviet, JSP. 
and Bean is defined as a component table by being as- 
sociated in a one-to-one relationship with each of the 
s screens of the GUI specification in the design document. 
Using the information In the component table ana tne 
design document, the name and variable of each com- 
ponent of che serviet, JSP, and Bean, the definition of 
methods, and each call relationship among the compo- 
te nents are automatically extract od to automatically gen- 
erate source codes. 

[0069] Fig.1 is a view depicting an example of a com- 
ponent table representative of the relationship among 
the screen, the serviet, JSP, and Bean of the Web ap- 

15 plication system to be designed and developed in this 
embodiment. The component table 1 01 comprises the 
screen name 1 02, the JSP name 103, the serviet filena- 
me 1 04, and the Bean filename 105, where each filena- 
me is defined to be associated In a one-to-one relation- 

20 ship with each screen image. It will be understood that 
the JSP name 103 has an extension sign oF u .jsp B , and 

the serviet filename 1 04 and Bean filename have an ex- 

tension sign of ".Java". For cx amp la, forthoscroon namo 
of Che ''New Order Screen", the JSP name 1 03 is "Order. 
Jsp", while the serviet filename 1 04 is a JSP name 103 
added by "Serviet 1 , orthe "OrderServletjava"* Similarly, 
the Bean filename 105 is a JSP name 103 added by 
"Bean", or Che "OrderBean.java". An "Error display 
screen" 106 is not associated in a one-to-one relation- 
s' ship with the serviet and Bean but is called by some 
servfets, and thus only the "Error.jsp" is defined accord- 
ing to the JSP name 103. 

[0070] Raferrlngto Flg.1 , reference numeral 107 des- 
ignates an external etorago unit for storing a variety 
35 pieces of information. The external storage unit 107 
stores information necessary to generate the source 
codes 110, 113, 116 of each of the components of the 
serviet, JSP, and Bean, which are defined in the com- 
ponent table 101. Reference numerals 108 and 109 
40 designate Information necessary to generate the JSP 
source code 1 1 0 and comprising a design document 1 0S 
for describing screen images, form data specifications, 
event specifications, and screen transition diagram; and 
template data log. Reference numerals 111 and 112 
4* designate information necessary to generate the serviet 
source code 1 1 3 and comprising a design document 1 1 1 
Tor describing package definition tables, screen transi- 
tion diagrams, error tables, form data specifications, and 
Bean public method tables; template data 11 2. and serv- 
50 let superclass source code data. Reference numerals 
114 and 115 designate information necessary to gener- 
ate the Bean source code 1 1 6 and comprising a design 
document 114 for describing package definition tables, 
class diagrams, sequence diagrams, form data specifi- 
cs cations, and Bean public method tables; and template 
data 115. 

[0071] Fig.2 is a view depicting an example of the con- 
figuration of a system for designing and developing a 
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Web application system. Referring to Fig.2, reference 
numeral 201 designates a terminal for inputting com- 
mands and operation with a mouse; reference numeral 
202 designates a central processing unit for storing 
functionality and data for Implementing the present in- 
vention; and reference numeral 203 designates an ex- 
ternal storage unit for storing various pieces of informa- 
tion, a deaign documont 204 ctored in the extern al etor- 
age unit 203 includes GUI specifications to be obtained 
from the requirements and business specifications pro- 
vided by customers for the development of a Web ap- 
plication system, and HTML files representative of 
screen design and each screen image, Referring back 
to Rg.1 # the design documents, template data, and 
source codes generated, designated by reference nu- 
merals 1 0S to 1 1 6, are stored in the external storage unit 
203. In the external storage unit 203, also stored is the 
servlet superclass source code data 212. 
[0072] The functionality stored in the central process- 
ing unit 202 comprises a component table generating 
unit 205 for reading screen Information from the GUI 
specification stored in the design document 204 to gen- 
erate a component table 206 representative of the rela- 
tionship amongthe screen, servlet JSP. and Bean. The 
functionality also comprises an automatic code gener- 
ating unit 207 for automaticaJly generating each source 
code of the servlet, JSP, and Bean by making use of a 
component table 206, The Information of the design doc- 
ument 204 such as the GUI specification and a system 
design document, and template data 208. The template 
data 208 includes source codes which are used as a 
template for each component upon generation of source 
codes and which form superclasses In the servlet. Each 
source code generated by the automatic codo g on orat- 
ing unit 207 is stored In servlet source code data 209, 
JSP source code data 21 0. and Bean source code data 
211. 

{0073) Fig.3 is a view depicting an example of the 
overall configuration of a Web application system which 
employs the servlet, JSP, and Bean, generated by the 
automatic code generating unit 207 of the system ac- 
cording to this embodiment. This Web application sys- 
tem Is used by a Web browser 302 on a client 301 . A 
HTML page 303 is displayed on the Web browser 302. 
A roquoet from the Web browser 302 la eent to e. aervcr 

304 via HTTP. The server 304 comprises a HTTP server 

305 and an application scrver306 which In turn includes 
a runtime environment of the servlet and JSP. 
[0074] The servlet JSP, and Bean, generated by the 
automatic code generating unit 207, are each executa- 
bly arranged on the application server 306 of the server 
304. Sending a request to the server 304 will cause a 
corresponding servlet 307 to execute according to the 
request. The servlet 307 issues a request to a corre- 
sponding Bean 308 to perform processing. Then, the 
Bean 308 uses a DB access object 31 0 to access a da- 
tabase 31 1 and then perform processing related to busi- 
ness and data processing, then holding the resulting da- 



ta. The DB access object 3 1 0 Is a class created through 
the analysis and design of business rules, or an existing 
reusable class. Subsequently, the servlet 307 passes 
the Bean 308 to a JSP 309 to call Ihe JSP 309. By re- 

5 trlevlng the resulting data held in the Bean 308, the JSP 
309 generates and then sends an HTML page back to 
the client 301 . The HTML page sent back as such is dis- 
played on tha Web browser 302. Here, the sen/let 307, 
JSP 309, and Bean 308 are defined in a one-to-one re- 

10 lationahip with the HTML pago 303 to be displayed on 
the Web browser 302. 

[0075] The servlet 307 receives a request from the 
Web browser 302, issues the request to the Bean 308, 
and calls the JSP 309, thus serving to connect between 

*5 and control each of them. The JSP 309 serves to display 
the output of an HTML page, while the Bean 308 serves 
for business transactions. Without using the Bean 308 
and the JSP 309, it is aJso possible to process a request 
from me weD browser 302 only witn the servlet 307, 

20 However, using the Bean 308 and the JSP 309 makes 
it possible to clearly separate their respective roles, 
thereby allowing each of their functions to be grasped 
in a simple manner. 

[0076] Now, referring to Fig. 4, a process flow is ex- 

25 plained for generating the component table 101 in the 
component table generating unit 205. First, all pieces of 
screen Information are read from the GUI specification 
stored in the design document 204 (step 401). The 
screen name and screen code name are retrieved from 

so the screen information (step 402). For example, the 
screen code name can be retrieved from the filename 
of HTML files created as each screen Image or may be 
defined as the screen information. Alternatively, the 
coroon cod© nemo can be inputted for each aereen from 

as the terminal 201 . Here, an explanation is given assum- 
ing that the screen name retrieved is "New orderscreen" 
and the screen code name is ''Order 1 '. Now, the retrieved 
screen code name is supplied with an extension sign of 
H .Jsp* to form a JSP name (step 403). The screen code 

40 name is added by "Servlet" and supplied with an exten- 
sion sign of "Java" to form a servlet filename (step 404). 
The screen code name is added by "Bean" and supplied 
with an exransion sign of "\java rt to form a Bean f nename 
(stop 405). Here, the filenames are defined as "Order. 

+s p p « r ,, OrdcrScrvlct.javn B , and "ordorBean.java", respec- 
tively. The screen name andthe filenames or the defined 
JSP name, servlet filename, and Bean filename are set 
to corresponding positions in the component table 101 
(step 406), It is determined whether processing, has 

so been performed on all pieces of screen Information re- 
trieved In step 401 (step 407). If not, processing is re- 
pealed from step 402 to 406 until all pieces of Informa- 
tion are processed. When all pieces of screen informa- 
tion have been processed, the component table 1 01 is 

55 finally generated and then control exits (step 408). The 
component table 101 generated in this step may be 
stored in the design document 204. 
[00771 Now, referring to Fig -5, a process flow is ex- 
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plained for automatically generating each source code 
of the servlet, JSP, and Bean in the automatic code gen- 
erating unit 207. First, The component table 101 gener- 
ated in the component table generating unit 205 is read 
(step 501). The screen name 102 is retrieved from the 
component table l oi (step 502) . An explanaTlon is given 
here assuming that the screen name retrieved Is "New 
order screen". It is checked whether all of the JSP name 
1 03, servlet filename 1 04 , and Bean filename 105 have 
boon cot oorrocpondlng To the eoreen name retrieved 
(step 503). Take the "Error display screen" 106 in Flg.1 
as an example. Here, the screen name is provided only 
with the JSP name 103 of ■Error.jsp a and thus control 
returns from step 503 to 502. If all filenames have been 
provided, The following processing will be performed. A 
servlet source code of "OrderServletJava" Is generated 
for the "New order screen", which Is retrieved In step 
502 (step 504). Similarly, a JSP source code of "Order, 
jsp" is generated (step 505) and a Bean source code of 
"OrderBean.Java" is then generated (step 506). It is de- 
termined whether processing has been performed on ell 
screens of the component table 101 retrieved in step 

501 (step 507). If not, processing ie repeated from ctep 

502 to 506 until all screens are processed. When all 
screens have been processed, then control exits. 
[0078] Now, referring to Rgs.6 and 7, a process flow 
is explained for automatically generating a servlet 
source code for r,he designated screen name. Upon gen- 
eration of a servlet source code, employed are a servler 
Template 701 , a package definition table 702, a compo- 
nent table 703, an error table 704, a form data specifi- 
cation 706, and a Bean public memod tab re 707. Refer- 
ring to Fig.7, reference numeral 708 designates a serv- 
let eouroe ocde to be generated. Firat, each of the 
names corresponding to The designated screen name 
1 02 is retrieved from the component tablo 1 01 (ctap 
601 ). An explanation is given here assuming that the 
screen name 102 designated Is "New order screen". 
"OrderServleTjava" of the servlet filename Is employed 
as the filename of a source code 706 to create a file 
(step 602). Then, the servlet template 701 is read from 
The template data 208 (step 603). The Template 701 de- 
scribes The basic frame of a servleT. 

[0079] Then, the package definition table 702 is read 
from the design document 204 to generate a package 
statement 709 and an imporr staTement 710 (step 604). 
A servlet package name Is outpuned to the package 
statement 709, while a Bean package name Is outpuned 
TO The Import Statement 71 0. The package declaration 

table 702 has the description of the package name off 
each component. "Orders ervlet* Is retrieved from "Or- 
derserylet.java" of the servlet filename 104 as The class 
name to generate a class definition unit 711 (step 605). 
For example, "BaseSorvlet" 712 is generated as a su- 
perclass servlet that the "OrderServlet" inherits. The 
"BaseServlet" 712 is provided as a class to be used In 
The development support system according to this em- 
bodiment. For example, H names()" 713 and a "business 



0"717 are a method defined by the ■ BaseServlet'* 712 
to be implemented In a subclass. The "namesO" 713 is 
a method for setting the name of JSP, Bean class, and 
an error JSP, which are employed by The servlet, while 
5 The "buslnessO" 717 is a method for defining the con- 
TenTs oTThe processing performed by the servlet. "Order. 
jsp M of the JSP name 103 retrieved in step 601 is gen- 
erated as a JSP 71 4 to be used (step ooo), and "Oraer- 
Bean" 715 of the Bean class name to be used is re- 

10 triovod and outputted from tho "OrderBean Java" of the 
Bean filename 1 05 (step 607). Then, the error table 704 
is read from the design document 204 to retrieve and 
generate an error JSP 716 corresponding to the "Or* 
derServtetJava" (step 608). The error table 704 associ- 
is atcs each servlet filename 1 04 with each error JSP 
name, where a JSP is designated for displaying the error 
generated upon execution of the sen/let. 
[0060] Subsequently, Che contents of the processing 
of the "buslnessO" 717 are generated. A variable is set 
using the Bean class name employed which has been 
retrieved in step 607 (step 609). The "bean" is a variable 
defined in the superclass "BaseServlet" and is used by 
bofng cact to Tho Boar dace ufiod In Th o cubofasc. Then , 

the screen transition diagram 705 is read from the de- 
sign document 204 to search the original screen by 
screen name (step 610), and then the form data speci- 
fication 706 corresponding to the original screen Is read 
from the design document 204 (step 611). When a re- 
quesT is sent from The Web browser 302 to The server 
304, the information described in the form of the HTML 
page 303 is added to the request as input data. The input 
data is designated In the Torm data specification 706. 
The Bean public method Table 707 of the Bean class to 
be used is read from the design document 204 (step 
612), and then a parameter of posted form data is re- 
Triovod to go no rate a code 71 a for totting The parameter 
to the Bean to be used (step 613). The Bean public 
method table 707 is a list of all methods that are made 
public in the Bean class Co be used, and defines access 
methods for Input data described in the form data spec- 
ification 706. Then, It Is checked whether the code 718 
has been generated to set parameters to all items de- 
scribed in the form data specification 706 (step 614), If 
not, the processing of step 613 Is repeaTed until all Items 
are processed, wnen all items nave been processed, 
conrrol exits from the definition of the "businessO" 717. 
Finally, the created Tile of the source code 706 is stored 
in the servlet source code data 209 (step 61 5), and then 
control exrts from the processing for automatically gen- 
erating the servlet source code. 
[0061] Referring to Fig.7, it has been explained that 
the "BaseServler 1 71 2 Is provided as a superclass. Now, 
referring to Fig.8, the source code of the superclass 
"BaseServleT" 712 is explained below. In Fig.8, refer- 
ence numeral 801 designates a source code and "Bas- 
eServlet" 802 shows the class nam of the superclass. 
[0082] First, reference numeral 803 designates a dec- 
laration or variables, employed by tne servlet, Toraeciar- 
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ing the JSP name, Bean class name, error JSP name, 
and a Bean object to be used. Reference numerals 604 
to B1 1 designating the definition of methods are shown 
below. Methods "initO" 807 and "doPostQ" 809 are de- 
fined by "HttpServlet" and implemented In this class. 
Method n bueineee() n 804 ie overridden in the eubalaee 
and describes actual processing. Method "attribute ()" 
BQ5 performs setting to allow JSP to arrcsc Bean, while 
method "forwardO" 806 calls JSP from the sen/let. Meth- 
od "doPostO" 809 determines the order of processing of 
the methods from 804 to 80S in order to allow the sub- 
class not to take the order of processing into consider- 
ation. This obviates the necessity for a developer, who 
is to create the subclass, to have special knowledge on 
the servlet. In addition, the 'InltO* 807 calls "namesO" 
808. Tne "names() H BOB is defined as an abstract meth- 
od and implemented in me subclass. Rerernng back to 
Fig.7. as shown by 714 to 716, the JSP to be used in 
the eervlet and fhc Dean class arc set. It is made pos- 
sible to create a servlet which can be executed only by 
setting each name with the ■namesO* 808. Method u er- 
rorO" 810 defines processing to be performed on an er- 
ror occurring upon execution of the servlet. Access 
methods are defined below for the variables declared in 
the variable declaration 803. 

[0063] Now, referring To Figs.9 and 1 0, a process flow 
is explained for automatically generating a JSP source 
code for the designated screen name. Upon generation 
of a JSP source code, employed are a JSP template 
1 001 , a screen Image 1 002, a component table 1 003, a 
form data specification 1005, and an event specification 
1 0O6. Referring to Fig. 1 0, reference numeral 1007 des- 
ignates a JSP source code to be generated. 
[0034] First, each of the names associated with the 
designated screen name 1 02 is retrieved from the com- 
ponent table 101 (step 901). An explanation is given 
here assuming That the screen name 1 02 designated is 
"New order screen 0 . The JSP filename "Ordar.Jsp" Is 
employed as the filename of the source code 1007 to 
create a file (step 902). Then, the JSP template 1001 is 
read from the template data 208 (sTep 903). TTre tem- 
plate 1001 describes the basic frame of JSP. 
[0085] Then, the Bean clasa nemo 1 009 "OrderBean" 
is retrieved from the Bean filename 105 "OrderBean. 
java" retrieved in step ©01 and generated (stop 004). A 
JSP syntax <Jsp ;useBean> 1 009 is to use the Bean 308 
in the JSP 309. Ascreen transition diagram 1 004 is read 
from the design document 204 to search a linked screen 
(step 905), and then "OrderConfirmServler is set to a 
linked servlet 1010 based on the servlet filename 104 
"Orde^Confi^mSarv|etjava ,, of the linked screen (step 
906). Then, the event specification 1005 and the form 
data specification 1006 are read from the design docu- 
ment Z04 (step 907), and an HTML file of the screen 
image 1 002 is read (step 908). The event specification 
1005 describes the contents of the processing per- 
formed upon pushing buttons or selection of lists in con- 
junction with Input check condition©. A Unkod eorvlot 



1010 determined In step 906, and the contents of the 
event specification 1005 and form data specification 
1006 upon which the contents of the HTML file read In 
step 90S are reflected are generated (step 909). Finally, 
s the created file of the sou rce code 1 007 is stored 1 n the 
JSP eouroe 00 dc data 21 0 (step 910), and then control 
exits from the processing for automatically generating 
the JSP source code. 

[0086] Now, referring to Rgs.11 and 12, a process 
flow is explained for automatically generating a Bean 
source coda fortha designated screen name. Upon gen- 
eration of a Bean source code, employed are a Bean 
template 1201 , a package definition table 1202, a com- 
ponent table 1203, a class diagram 1204, a sequence 
diagram 1205, a Bean public method table 1206, and a 
form data specification 1207. Referring to Flg.12, refer- 
ence numeral 1208 designates a Bean source code to 
be generated. 

[0087] First, each of the names associated with me 
designated screen nam© 1 02 is retrieved from the com- 
ponent table 101 (step 11 01). An explanation js given 
here assuming that the screen name 102 designated is 
•New order screen* 4 . The Bean filename "OrderBean. 
java" is employed as the filename of the source code 
1303 to create a file (step 11 02). Then, the Bean tem- 
plate 1201 is read from the template data 208 (step 
11 03). The template 1 201 describes the basic frame of 
Bean. 

[0068] Then, the package definition table 1 202 Is read 
from the design document 204 to generate a package 
statement 1209 (step 1104). The Bean package name 
ie generated in the package statement 1209. A class 

name "OrderBean" is retrieved from the Bean filename 

1 05 "OrderBean.java" to generate a class definition unit 

1210 (step 1106), The class diagram 1204 is read from 
the design document 204 to search the superclass Bean 
which the "OrderBean" inherits, and then generate the 
class name 1211 thereof (step 11 06). Then, defined are 
the contents of the processing of "doBuslnessO" 1212 
which is a method executed by a servlet. The sequence 
diagram 1205 ts read from the design document 204 to 
define in accordance with the sequence diagram 1205 
and generate the "doBusiness () " 1 21 2 (step 1 1 07). The 
class diagram 1 204 and the sequence diagram 1 205 are 
45 a document which ie docoribod in UML (Unified Mode- 
ling Language) notation. 

[0089] Then, theform data specification 1207 and the 
Bean public method table 1 206 are read from the design 
document 204 (stop 1108), and variable declarations 

$0 1213 are generated for all items described in the form 
data specification 1207 (step 1109) to define and gen- 
erate all methods of the Bean public method table 1206 
(step 1110). Finally, the created file of the source code 
12GB is stored in the Bean source code data 211 (step 

5$ 1112), and then control exits from the processing for au- 
tomatically generating the Bean source code. 
[0090] Referring to Fig. 13, it will be explained that the 
Bean ie a component that ia provided with all pieces of 
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information necessary for screen display. Fig.13 is a 
view depicting tne relationship between the screen in- 
formation and Bean. In Fig.13, reference numeral 1301 
designates a screen Image and an explanation is given 
to an example of "New order confirm screen". Reference 
numeral 1 302 designates the clacc of Basin, The name 
displayed In a partition 1303 above the class 1302 is a 
class name, showing thai th© ■OrdarConfirmBean" cor- 
responding to the "New order confirm screen" is the 
class name of the Bean. A lower partition 1 304 Indicates 
the attribute of the cla38. The "OrderConfirmBean" is 
provided with all pieces of Information necessary to dis- 
play th© "New order confirm screen", the information be- 
ing retrieved by JSP and displayed as an HTML page. 
The inTormatlon whicn is necessary for screen display 
and Inputted to theform is def ined in the form data spec- 
ification 1 207 and the Sean public method tabic 1 206 of 
Fig. 12. 

[0091] Now, a second ombodimont of The present in- 
vention Is explained below. Here, an example Is ex- 
plained which employs a servlet, JSP, and Bean, de- 
scribed later with reference to FrgJ4, for designing and 
developing a Web application system. In particular, the 
present invention is characterized in that the name of 
each component of the servlet, JSP, and Bean Is defined 
by being associated with each screen in the screen 
specification provided by design information. Using the 
component definition and thB contents of Che design In- 
formation, the definition of methods and the call relation- 
ship between the components are automatically extract- 
ed to automatically generate source codes. 
[0092] Fig. 14 is a view depicting an example oF the 
overall configuration of a Web application system which 
employs the servlet, JSP, and Bean, designed and de- 
veloped in this embodiment. This Web application sys- 
tem Is used by a Web browser 1 402 on a client 1 401 , A 
HTML page 1403 appears on the Web browser 1402. A 
request from the Web browser 1402 is sent to a server 
1 404 via HTTP. The server 1 404 is provided with a HTTP 
server 1405 and an application server 1406, While the 
application server 140Q includes at runtime environment 
of a servlet and JSP, 

[0009] A corvtot 1407, JSP 1408, and Bean 140Q are 
arranged on the application server 1406 of the server 
1 404, A request sent from the Web browser 1 402 of the 
client 1 401 will cause the corresponding servlet 1 407 to 
be activated in accordance with the request. The servlet 
1407 issues a request to the corresponding Bean 1409 
to perform processing. In addition, the Bean 1409 uses 
a business class and DB access class 141 0 to access 
a database 1411, then performing data manipulation 
necessary for ousmess transactions to execute busi- 
ness transactions and data processing. The Bean 1409 
holds the resulting daLa. The business class and the DB 
access class 141 0 represent a class created through the 
analysis and design of business rules or a reusable ex- 
isting class. Th n, the servlet 1407 passes the Bean 
1409 to the JSP 140A, calls the JSP 140S, and Issues 



a request thereto to gen rate an HTML page. The JSP 
1408 retrieves the resulting data held in the Bean 1409 
to generate an HTML page and send it back to the client 
1 401 . The HTML page 1 403, which has been sent back, 
£ Is displayed on the Web browser 1402. 

[0004] Afi. docoribod abova, the servlet 1 407 recorvee 
the request from the Web browser 1402, issues a re- 
quest to the Bean 1409. and calls the JSP 1408, thus 
serving to connect between and control each of them. 
The JSP 1408 serves to display the output of an HTML 
page, while the Bean 1409 serves to assemble business 
using the business class and the DB access class 1 41 0. 
execute actual processing, and hold the resulting data. 
Their respective roles are clearly separated, thereby al- 
lowing each of their functions to be grasped in a simple 
manner. 

[0099] Rg.19 depicts me relationship Deiween some 
recipient components and response components, em- 
ployed in a Web application syetem according to this 
embodiment. An input screen 1510 shows a screen for 
sending a request to the server 1404. The request is 
processed on the server and the resulting data is sent 
back to the client 1 401 as an output screen 1 504. In Rg. 
14, the servlet 1407 corresponds to a recipient compo- 
nent 1502, while the JSP 1406 corresponds to a re- 
sponse component 1503. Fig. 14 shows the configura- 
tion of a Web application system employing The servlet, 
JSP, and Bean. It is also possible to receive a request 
from the Web browser 1402 and send back the resulting 
data thereto only with the servlet 1407 or only with the 
JSP 1408, without using the JSP 1406 and the Bean 
1400. Preparation of recipient window parts 1 (1S05) 
and response window parts 1 (1 506) allows the received 
request to be assigned to a corresponding recipient part 
or the resulting data to be assigned to a corresponding 
response part Accordingly, recipient components and 
response components are not always associated with 
each other in a one-to-one relationship. Components 
should be defined by selecting an appropriate relation- 
ship in accordance with the configuration of the Web ap- 
plication system to De developed. Mere, an explanation 
is given to such a case where a recipient component 
and reeponse component are associated with each oth- 
er in a ona-to-one relationship such as a recipient part 

7 (1507) and rospO-nso part 7 (1508), 
[0096] Figs.16 and 17 show examples of defining a 
one-to-one relationship between the recipient compo- 
nent 1502 and the response component 1503. An event 
1601 shows, for example, the pushing a button upon 
sending a request from the input screen 1501 to the 
server. A condition 162 is applied to the call made by 
the recipient component 1502 to the response compo- 
nent 1503 as a result of processing on the server. As an 
exception, when the condition 182 Is set, the recipient 
component 1 502 and the response component 1 503 are 
associated with each other in a one-to-one relationship. 
[0097] In Fig. 16, the recipient component 1 502 for re- 
ceiving a request from the input ecroon 1 601 depends 
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on the output screen 1504. The recipient component 
1502 and the response component 1503 are created 
corresponding to the output screen 1504, considering 
that the request from rhe input screen 1501 is to output 
the subsequent output screen 1504. A screen C 1603 
□f the input screen 1301 Includes a recipient component 

1502 for sending a request, which is different depending 
on the ovont 1601 . 

[0098] On the other hand, in Fig, 1 7, the recipient com- 
ponent 1 502 depend on tha input screen 1501 . The re- 
quest from the input screen 1 501 is received by the cor- 
responding recipient component 1502. The recipient 
component 1502 assigns the response component 

1503 in accordance with the event 1601 and condition 
162. The recipient component 1502 and the response 
component 1 503 are created corresponding to the input 
screen 1501 and the output screen 1504, respectively. 
A plurality of events 1601 , such as on a screen C 1 701 
of tne input screen 1 501 , will be received and processed 
by a corresponding recipient component 1502, Given 
below is an explanation of the definition of the relation- 
ship between components shown in Fig. 16. 

[Q099] Rg.1 8 duplets an example of the definition, ex- 
pressed in a tabular form, of the relationship among the 
screen name, servlet, JSP, and Bean of the Web appli- 
cation system which is designed and developed in this 
embodiment. A component definition table 1801 con- 
sists of a screen name 1 802, a screen ID 1 803 t a servlet 
name 1 804, a Bean name 1 805, and a JSP name 1 606, 
and defines names corresponding to each screen Im- 
age. The screen name 1 802 represents the name of a 
screen to be generated by a component wltn a combi- 
nation of the servlet name 1804, the Bean name 1805, 
end the JSP neme 1806. A eervJot given by the eervlet 
name 1804 is the recipient component 1502, while a 
JSP given by the JSP name 1 806 is the response com- 
ponent 1503. 

A Bean given by the Bean name 1805 is a component 
which executes the processing requested by the servlet 
and of which information is retrieved by the JSP upon 
generation of an HTML page. 

[0100] The servlet name 1804 and the Bean name 
ibo5 are not supplied wltn an extension sign and the 
name of a class file, whereas the JSP name 1 806 is sup- 
plied with an extension sign of M .jsp u . For example, for 
the screen name 1802 "Top* 1807, the servlet name 
1804 is "DefaurrServlef In which the screen ID 1803 
"default" with the firsi character being written with its up- 
per-case letter is added by "Servlef . Similarly, the Bean 
name 1 805 is "DefauHBean" in which the screen ID 1 803 
"default* with the first character being written with its up- 
per-case letter is added by "Bean". The JSP name 1 806 
is "defaufc.jsp" in which the screen ID 1803 is supplied 
with an extension sign of ",jsp M . 
[0101] In some cases, the servlet name 1 604 and the 
Bean name 1805, or the JSP name 1806 and the Bean 
name 1805 are associated with each other in an n-io-m 
relationship such as "Order confirm" 1 809. In this case, 



the Bean name 1805 cannot be defined on the screen 
ID 1803, and therefore edited for addition. Furthermore, 
for "Error display" 1 81 0, only "crror.jsp u 1 811 of the JSP 
name 1 606 is defined. This is called by some servlets. 

9 Given below is an explanation of a one-to-one relation- 
ship among tne serviet name 1504, tne Bean name 
1805, and the JSP name 1806. 

[0102] A component definition table 1 901 depicted In 
Fig.19 shows an example of the definition of a Dne-to- 

10 one relationship among the eorvlet nemo 1804, the 
Bean name 1805, and the JSP name 1 806, correspond- 
ing to each screen name 1 802, 

P>1 03J Fig.20 depicts an example of the configuration 
of a system for designing and developing a Web appli- 
es cation system. In Rg.20, reference numeral 2001 des- 
ignates a terminal for the input of commands and oper- 
ation with a mouse; reference numeral 2002 designates 
acentraJ processing unitfor implementing various func- 
tionality, described later; and reference numeral 2003 
designates an external storage unit for storing various 
pieces of information. A design document 2004 stored 
in the external storage unit 2003 includes a design doc- 
ument euch afi GUI epooifiotfJone to be obtained from 
the requirements and business specification provided 
by customers for the development of a Web application 
system, and HTML files representative of screen design 
and each screen image. Component definition data 
2005 Include the component definition table 1901 de- 
picted in Fig.19. Template data 2006 include templates 
employed upon generation of the source code of each 
component, source codes or superclasses of servlet 
and Sean, and class files. Source code data 2007 in- 
clude the source codes of the servlet, JSP, and Bean, 
[0104] The central processing unit 2002 includes and 
executes software which Implements the following three 

functions. A component definition ganorating/aditing 
unit 2008 reads design information from the GUI spec- 
ification stored in design document 2004 to generate 
and store in the component definition data 2005 the 
component definition table 1901 for defining the rela- 
tionship among the screen, servlet, JSP, and Bean, Fur- 
thermore, it is possible to edit the generated component 
definition table 1901 on a terminal 2001 using the com- 
ponent definition generating/editing unit 2008. A code 

generating unit 2009 generates automatically tne 
source code of each of the servlet, JSP, and Bean, using 
the component definition table 1901 stored In the com- 
ponent definition data 2005 and the design document 
2004 such as the GUI specification or the system design 
document- Upon generation of source codes, used are 
the template and superclass of each of the components 
stored in the component definition data 2005, Each 
source code generated in the code generating unit 2009 
is stored in the source code data 2007. Using the com- 
ponent definition table 1901 stored in the component 
definition data 2005, a code editing unit 201 0 retrieves 
the source code of each component corresponding to 
the screen to oe developed from the source code data 
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2007 to edit the source code on the terminal 2001 using 
an editor. 

[01 OSJ F1g.21 depicts an example of a developing pro- 
cedure for designing and developing a Web application 
system according to this embodiment. First, a servlet is * 
created and then a Bean ana a jsp are created in tnat 
order In the creation of theservtet, a servlet source code 
2108 is created using design information 2102 with ref- 
erence to a servlet template 21 01 . For example, the de- 
cign Information 21 02 noooccary for creating the eervlot *o 
includes the component definition table 1901, a pack- 
age specification 2104, a screen transition diagram 
2105, a form data specification 2106, a session man- 
agement specification 2107, and an error specification 
2108. is 
[01 06] The package specification 21 04 describes the 
definition and name of each component. The screen 
transition diagram 2105 shows the transition between 
screens. Upon sending a request from a Web browser 
to a server, the contents described In the form of an 20 
HTML page are added to the form data. The contents 
of the form data are described in the form ri?ta specifi- 
cation 2106. The session management specification 
2107 describes the information that is taken over be- 
tween the screens. The error specification 21 08 de- 2s 
scribes the contents of The processing That is performed 
when an error has occurred as a result of processing on 
the server. 

[01 07J Subsequently, the Bean is created, Upon cre- 
ation of the Bean, a Bean source code 2111 Is created so 
using design information 211 0 with reference to a Bean 
template 2109. For example, tne design information 
2110 necessary for creating the Bean Includes the com- 

ponont definition table 1 001 , tho package specification 
21 04, the screen transition diagram 21 05, the form data 35 
specification 21 06, a check list 2112, a class specifica- 
tion 21 13, a method specification 2114, and a sequence 
diagram 2115. 

[01 08] The check Nst 21 1 2 describes items such as a 
value check or validity check of the form data provided 40 
when a request Is sent. The class specification 2113 de- 
scribes the Bean, a business class of Rg.14, the class 
diagram of the DB access dass 1410, and the outline, 
attribute and method of a class. The method specifica- 
tion 21 1 4 describes In detail the method provided Dy tne 
class of the class specification 2113. The sequence di- 
agram 2115 shows in a diagram the flow of method 
processing. The class diagram of the class specification 
2113 and the sequence diagram 2115 are a document 
which is described in UML (Unified Modeling Language) so 
notation. 

[0109J Finally, the JSP Is created. Upon creation of 
the JSP, a JSP source code 21 1 8 is created using design 
inf ormation 21 1 7 with reference to a JSP template 21 1 6. 
For example, the design information 2117 necessary for ss 
creating the JSP includes The component definition table 
1901 , a screen Image 2119> the screen transition dia- 
gram 21 oq\ an event specification size, the form data 



specification 21 06, the class specif ication 21 1 3, and the 
method specification 2114. 

[0110] The screen image 21 19 defines the image of 
each screen of the GUI specification and is created in 
an HTML file. The event specification 2120 describes 
me check Items or processing on tne diem to check in- 
puts such as pushing buttons or selection of lists in an 
HTML page Form. 

[0111] The system according to this embodiment al- 
lows the oode generating unit 2009 to automatically gen- 
erate each of source codes 21 03 , 2 1 1 1 , 21 1 8 of the serv- 
let, JSP, and Bean, which are In turn stored as the 
source code data 2007 in the external storage unit2003. 
In addition, the code editing unit 2010 is used to edit the 
source codes. 

[0112] The flow of processing for generating the com- 
ponent definition table 1901 with the component defini- 
tion generating/editing unit 2008 is explained below with 
reference to Fig.22. First, all pieces of screen informa- 
tion are read from the GUI specification stored In The 
design document 2004 (step 2201), The screen name 
and ID are retrieved from the firei screen Information 
(etop 2202). For example, the screen ID may bo re- 
trieved from the filename of each HTML file prepared as 
a screen image or may be defined In the screen infor- 
mation. Alternatively, the screen ID may be entered on 
the terminal 2001 for each screen, Here, an explanation 
is given assuming that the retrieved screen name is "Or- 
der confirm" and the screen ID is "confirm". 
[0113] Then, the retrieved screen ID with the first 
character being written with its upper-case latter is add- 
ed Dy "Servjer to form a servlet name (step 2203). sim- 
ilarty> the screen ID with the first character being written 

with Eta upper-caBG latter ie addod by "Boan" to form a 
Bean name (step 2204). The screen ID is supplied with 
an extension sign of ".Jsp" to form a JSP filename (step 
2205). Thus, the name of each of the components fe de- 
fined as ''ConflrmServlet", "ConflrmBaan u t and "confirm, 
jsp", respectively. A set of the screen name, the screen 
ID, and the defined servlet name, Bean name, and JSP 
name is added to the component definition table 1 901 
(step 2206). 

[01 14] Then , it is checked whether all pieces of screen 
information retrieved in step 2201 have been processed 
(step 220T). If not, control returns so as to repeat the 
processing from step 2202 to 2206 until all screen infor- 
mation has been processed. Finally, if all pieces of 
screen information have been processed, the compo- 
nent definition table 1901 is stored in the component 
definition daia 2005 and then control exits (step 2208). 
Here, the generated component definition table 1901 
may be stored in the design document 2004. 
[01 15] Now, referring to Bg.23, a process flow is ex- 
plained for automatically generating each source code 
of the servlet, JSP, and Bean in the code generating unit 
2009, First, the component definition table 1901 gener- 
ated by the component definition generating/editing unit 
zoob is read (siep 230 1 ). The screen name 1802 is re- 
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tn"9VGd from the component definition table 1901 (step 
2302). An xplanetfon is given here assuming That The 
screen name retrieved is "Order confirm*. The name of 
each component corresponding to the screen name is 
retrieved (step 2303). ft is checked whether all of the 
servlet name 1004, Bean name 1805, and JSP name 
1 806 have been set corresponding to the screen name 
retrieved (step 2304). Take the * Error display" 1811 in 
Fig.1 9 as an example. Here, the screen name is provid- 
ed only with the JSP name 1 fiQG "orror.j^p" and thus 

control returns from step 2304 to 2302. If all names have 
been set, the following processing will be performed. 
[01 16] First, a sen/let source code of "ConfirmServlet, 
Java" Is generated for the "Order confirm", which is re- 
trieved In step 2302 (Step 2305). Similarly, a Bean 
source code of "ConflrmBeanJava" Is generated (step 
2306) and a JSP source code of "confirm jsp" Is then 
generated (step 2307). It is determined whether 
processing has been performed on an screen names ot 
the component definition table 1 901 that has been read 
in step 2301 (step 2307), If not, processing is repeated 
from step 2302 to 2307 until all screen names have been 
processed. When all screen names have been proc- 
essed, then control exits. Incidentally, In the foregoing, 
the source codes are generated after it Is checked In 
step 2304 that all of the sen/let name 1 804, Bean name 
1 605 , and JSP name 1 806 have been set corresponding 
to the screen name. However, the check In step 2304 is 
not always inevitable. If any one of the sen/let name 
1804, Bean name 1805 r and JSP name 1806 has been 
sat, its source code may be generated. 
[01 IT] Now, referring to Figs.24 and 26\ a process 
flow is explained for automatically generating a servlet 

eourco codofortho dockjnatod corocn nam 9 in the oode 
generating unit 2009. It is assumed that the name of 
each component defined In the component definition ta- 
ble 1901 Is given In advance. An explanation is given 
here assuming that the screen name 1 602 designated 
is "Order confirm" and the names of the components are 
"ConfirmServlet", ^ConfirmBean'', and "conflrm-Jsp", re- 
spectively. Upon generation of a servlet source code, 
employed are the servlet template 21 01 , the component 
doTlnmon tabte 1 901 from the design document stored 
in the design document 2004, the package specification 
2104, the ooreen transition diagram 21 OS, the form data 
specification 2106, th& session management specifica- 
tion 21 07, and the error specification 21 06. Referring to 
Fig. 25, reference numeral 2501 designates a servlet 
source code to be generated. 
[0118] First, created Is a file "ConfirmServlet. java" 
with the filename of the given servlet name 1804 and 
with an extension sign of ".Java" (step 2401). Then, a 
servlet template list is read from the template data 2006 
(step 2402). The template data 2006 stores the basic 
frame of a servlet as well as servlet templates for various 
use and superclasses. Then, the template 2101 for use 
with the servlet to be created is selected from the tem- 
plate list that has been read (step 2403). The selected 



template2l01 Is used as a mod el for creating the source 
code 2501 . Here, in some cases, the employed template 
2101 may be individually selected or may have already 
been set. 

s [0119] Then, the package specification 2104 Is read 
to generate a package statement 2502 and an import 
statement 2503 (step 2404). The servlet package name 
is outputted to the package statement 2502, while the 
Bean package name is outputted to the import state- 
ment 2503, Then, the eervlet name 1 804 "ConfirmSorv- 
lef Is employed as the class name and outputted to a 
class declaration 2504 (step 2405). A b service()" 2505 
Is a method provided by the servlet API and would be 
executed In accordance with the request from a client. 
In the subsequent processing, The contents of the 
processing of the 'serviceO* 2505 are generated. 
[0120] First, the given Bean name 1605 "Confirm- 
Bean" is generated from the servlet and outputted as a 
Bean class name 2506 to be used (step 2406). The orig- 
inal screen is searched in the screen transition diagram 

2105 (step 2407). Than, the Torm data specification 

21 06 oF the original screen is read as an item name 2507 
for use upon rotrio,\/al of a parameter, the parameter be- 
ing then retrieved and set to the Bean (step 2408). Sub- 
sequently, the session management specification 2107 
Is read (step 2409) to generate an item name 2508 of 
the parameter retrieved from the session (step 2410). 
[0121] Similarly, the parameter to be stored in the ses- 
sion and an item name 251 o are generated (step 241 1 ). 
A method "doTaskO" 2509 is used to Issue a request 
from the servlet to the Bean for processing. Then, the 
error specification 21 06 is read to generate tne contents 
of the processing upon occurrence of an error (step 

2412). At the end of the B 8orvico()" 2606, the given JSP 

name 1 806 "confirm .jsp" is generated as a JSP name 
2512 tD be called from the servlet (step 2413). Finally, 
the file of the generated source code 2501 Is stored In 
the source code data 2007, and then control exits from 
the processing for automatically generating the servlet 
source code (step 2414). 

[0122] Figs .24 and 25 show examples for generating 
the servlet source code. In these examples, the tem- 
plate 21 01 is employed as a model tor automatical ty ex- 
tracting and generating necessary items from the con- 
tents of the design document 2004 to output the items 
where appropriate. Now, referring to Fig.26, rt will be ex- 
plained below that source codes can also be generated 
by inheriting as a template a superclass prepared as a 
class to be used in the development system according 
to this embodiment. In Fig.26, reference numeral 2601 
designates a servlet source code to be generated. Since 
most of common processing is defined in a superclass, 
only unimplemented or insufficient processing may be 
developed. In addition, the source code 2601 of Flg.26 
can be generated more easily than the source code 
2501 of Flg.25. 

[0123] When a source code Is created by inheriting a 
superclass, a superclass is selected In step 2403 of Fig. 
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24 for the template 21 01 to be used. Then, the super- 
class is outputted to a superclass name 2602, which in- 
herits the superclass, upon outputllng the class decla- 
ration in step 2405. Most of processing Is Implemented 
In the superclass of the servlet, for example, methods 
"InHO" £Q03, M bef6reTaak()" 2604, and "afterToskO" 

2605 are only declared. These methods 2603, 2604, 

2606 are defined In th© *ubolaG6, The method "init()" 
2603 carries out setting upon Initialization and desig- 
nates the Bean name or JSP name, which are to be used 
Dr called by the servlet, using n setBeanName()"2606 or 
"se[JspPage() g 2607. Then , the contents of the process- 
ing to be performed before the Bean is requested for 
processing are Implemented In the ^fore-TaskO" 2604, 
whereas the contents of the processing to be performed 
after the Bean has performed processing are Imple- 
mented in the "afterTaskQ* 2605. For example, session 
management is carried out here. As described above, 
developers can develop a servlet only Dy implementing 
the B lnit()" 2603, the 'beforeTaskO* 2604, and the "aUer- 
TaakO" 2605. 

[0124] In Flg.26, ll has been explained above that 
source codes can be generated by Inheritino as a tem- 
plate a superclass prepared as a dass to be used in the 
development system according to this embodiment. 
Now, referring to Fig.27 r an example of a superclass 
source code is explained below. In Flg.27, reference nu- 
meral 2701 designates a superclass source code and a 
class name 2702 is "BaseServlet 11 . 
[0125] First, reference numeral 2703 Is the declara- 
tion of a variable employed in the "BaseServlet", which 

declares the JSP name, the Bean name, and the Bean 
object to be used. Reference numerals 2704 to 2712 
dofilgnato tho dof InWan of mothodft tod low. A method "in- 
rt()" 2704 carries out setting upon initialization and is im- 
plemented in the subclass to set the Bean name and 
JSP name, which are used or called by the servlet. A 
method "servlceO" 2705 Is provided by the servlet API 
and will be executed when required by a client. In the 
'serviceO* 2705 , the methods from 2707 to 2712 arc ex- 
ecuted In the predetermined order For this reason, the 
subclass that inherits the superclass "BaseServlet" 
2702 has no need to take tne order or processing into 
consideration. This obviates the necessity for a devel- 
oper, who ie to create the eubclaes, to have special 
knowledge on the servlet. Definition of the "init()" 2704 
in the subclass would make rt possible to create an ex- 
ecutable servlet. 

[0126] A method "createO" 2706 creates an object 
with the designated Bean name, while a method 
"doTaskO* 2708 issues a request to the Bean for 
processing. The processing before and after the 
"doTaskO* 2708 is described in methods "beforeTask() 
" 2707 and "afterTaskO" 2709, respectively, and is im- 
plemented in the subclass if necessary. A method "cai- 
IJsp(r27l0cailstheJ$P of the JSP nam designated. 
Occurrence of an exception while the "servlceO" 2705 

is being executed would cause a method "errorQ* 271 1 



to execute error processing. Reference numeral 2712 
is the definition of an access method for a variable 2703 
employed in the "BaseServlet". 
[0127] When a servlet source code is automatically 

s generaied In the code generating unit 2009, a template 
is selected corresponding to the servlet to be created, 
An example of a method for selecting the template is 
explained below with referenoeto Rg.20. In Flg.26, ref- 
erence numeral 2801 designates an operation screen 

10 for a development support system according to this am. 
bodlment. In a region 2802 to the left of the screen, dis- 
played is a system name of an "Order system" 2803 
which is to be designed and developed, in a hierarchical 
structure provided just below the "Order system", a 

1 5 screen name "Order confirm" 2804 is displayed and fol- 
lowed by the servlet, JSP t and Bean in sequence. This 
hierarchical structure represents the contents of the 
component definition table 1 901 that is defined by the 
component definition generatlng/edlxlng unit 2006. 

zo [0128] Here, an explanation is given to a case where 
a template is selected for use In generating - Conflrm- 
Servlct" 2805 of me servlet. Reference numeral 2806 
designates a template selection screen for allowing a 
template Df the servlet to be selected, where the tern- 

& plate list read from the template data 2006 is displayed 
in list form. The list displayed includes a name 2807 In- 
dicating the template and a code name 2808. Selection 
of a template to execute an execution button 2809 on 
the template selection screen 2806 will make the select- 

30 ed template available, in addition, the execution of a 
contents explanation button 281 0 would cause ascreen 
2011 to be displayed, in which the template selected is 
explained in detail. 

[0120] Like the servlet, a template is selected and 

35 used as a model upon generation of Bean and JSP 
source codes, which is described with reference to Figs. 
30 and 33, Referring to Rg,29, explained Is an example 
of a method for selecting each of the Bean and JSP tem- 
plates. Like the template selection screen 2806 of Pig, 

40 26 , there are provided a Bean template selection screen 
2901 and a JSP template selection screen 2904. In the 
list displayed on each screen, displayed are template 
names 2902, 2903 and code names 2903, 2906. In the 
Bean template selection screen 2901 , shown is the con- 

45 figuration of otaeeee in a deed hierarchy. In addition, In 
the JSP template selection screen 2904, a plurality of 
templates or a combination of templates can be used. 
[0130] Now, referring to Figs.30 and 31, a process 
flow is explained for automatically generating a Bean 

£0 source code for the designated screen name in the code 
generating unit 2009. It Is assumed that The name of 
each component defined in the component definition ta- 
ble 1901 is given in advance. An explanation is given 
here assuming thai the screen name 1802 designated 

55 is "Order confirm" and the name of the component is 
"ConfinmBean". Upon generation of a Bean source 
code, employed are the Bean template 2109, the com- 
ponent definition table 1901 , the package epecifjeation 
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2104 from the design document stored In the design 
document 2004, the screen transition diagram 21 05, the 
form dara specification 2106, the check list 2112, the 
class specification 211 3, the method specification 2114, 
and sequence diagram 2115. Referring to Flg.31 , refer- 
ence numeral 3101 designates a Bean source code to 
be generated. 

[0131] Firct, croatod ic a fil© ,, Co^>flrmBean.java ,, with 
the filename of the given Bean name 1 805 employed as 
the filename and with an extension sign of ".Java* (step 
3001 ), Then, a Bean template list is read from the tem- 
plate data 2006 (step 3002). Like the sen/let template, 
the template data 2006 stores the basic frame of a Bean 
as well as Bean templates for various use and super- 
classes. Then, the template 21 09 for use with the Bean 
to be created Is selected from the template list that has 
been read (step '(3003). The selected template 2109 is 
used as a model for creating the source code 3101 . 
[0132] Then, che package specification 2104 is read 
to generate the package statement 3102 (step 3004). 
The Bean package name is generated in the package 
statement 3102. Then, the Bean name 1S05 "ConRrm- 
Bean" Is employed as the class name and outputted to 
a class declaration 3103 (step 3005), Furthermore, the 
class specification 2113 Is searched for the superclass 
of the target Bean class "ConfirmBcan" to generate the 
name (step 3006). 

[0133] A method "doTaskO" 31 04 Is executed by the 
servlet and the contents of the processing 31 05 are Im- 
plemented here with the Bean. Then, the sequence di- 
agram 2115 is read to output the contents of the 
processing In accordance with the sequence diagram 
2115 (step 3007). Then, the contents of the processing 
of a method "chock() u 310fi aro gonorotod. Tho "chock 
0" 31 06 is called from the n doTask() n 31 04 to check the 
parameter passed from the servlet. First, the original 
screen is searched in the screen transition diagram 

2105 (step 3006). Then, the form data specification 

2106 of the original screen Is read to generate an Item 
name 3107 for use upon retrieval of a parameier (step 
3009). The check list 2112 is read to generate check 
processing 310a for checking the parameter generated 
In step 3009 (step 301 0). 

[0134] Then, the attribute of the target Bean class 
"CanflrmBoan" lc retriovod from tho olaoe opooifioation 
2113 to generate a declaration 3109 of the attribute 
(step 3011). Then, generated are a retrieval method for 
retrieving and a setting method 3110 Tor setting the at- 
tribute (step 301 2). Furthermore, the method specifica- 
tion 2114 Is read to generate methods other than the 
"doTaskO" 31 04, the "checkO" 31 06, the attribute setting 
method, and th© attribute retrieval method 3110 (step 
3013). Finally, the file of the generated source code 
3101 is stored in the source cods data 2007, and then 
control exits from the processing for automatically gen- 
erating the Bean source code (step 3014). 
[0135] Now, referring to Fig.32, it will be explained 
that th© Bean is a component that is provided with all 



pieces of information necessary for screen display. Fig. 
32 is a view depicting the relationship between the 
screen information and Bean. In Fig.32, reference nu- 
meral 3201 designates a screen image and an explana- 

s tion is given to an example of "Order confirm" screen. 
Reference numeral 3202 designates the class of BBan. 
The name displayed in a partition 3203 above the class 
3202 ib a cIbbb name, ahowing thattha "ConfirmBean* 
corresponding to the "Order confirm 0 is the class name 

10 of Che Bean . A lower partition 3204 indicates tho attrib uto 

of theclass. The^ConfirmBean" is provided as attributes 
with all pieces of Information necessary to display the 
"Order confirm' 1 screen, those attributes being retrieved 
by JSP and displayed as an HTML page. The informa- 
tion which is necessary for screen display and entered 
to the form of the HTML page is described in the form 
data specification 2106 of the design document stored 
in the design document 2004. 

[0136] Now, referring to Flgs.33 and 34, a process 

20 flow is explained for automatically generating a JSP 
source code for the designated screen name In tho code 
generating unit 2009. It is assumed that the name of 
each component defined in the component definition ta- 
ble 1901 is given in advance. An explanation is given 

2s here assuming that the screen name 1 802 designated 
Is "Order confirm*, and the name of the Bean and JSP 
components is "ConfirmBean" and "confirm.jsp", re- 
spectively. Upon generation of a JSP source code, em- 
ployed are the JSP template, the component definition 

30 table 1 901 , tho screen image 21 1 9 from the design doc- 
ument stored in the design document 2004, the screen 
tranaldon diagram 2105, the event specification 2120, 
the form data specification 2106, the class specification 
2113, and Tho method specification 2114. Referring to 

ss Fig. 3 4, reference numeral 3401 designates a JSP 
source code to be generated. 

[0137] First, created ie a file "Confirm jsp" with the 
filename of the given JSP name 1606 employed as the 
filename (step 3301 ). The HTML file of the screen image 
*o 211 9 of che "Order confirm" screen is read from the de- 
sign document (step 3302), and then the contents of the 
HTML file th at has been read are generated (step 3303). 
"men, a J3P template fist is reao from the template data 
2006 (step 3304). The template data 200© stores the 

baeic framework of a JSP ae well ae JSP templatoe for 
various use, Then, the template 2116 for use with the 
JSP to be created is selected from the template list that 
has been road (stop 3305). The selected template 211 6 
is used as a model for creating a source code 3401 by 
50 processing the contents of the HTML file generated in 
step 3303. 

[0130] Then, the Bean name 1805 "ConfirmBean' 1 
given is generated as a class 3402 to be used in JSP 
(step 3306). Tag <jsp:useBean> 3402 is a syntax for us- 
3$ Ing th e Bean In JSP. The event specification 21 20 Is read 
to generate a script definition 3403 for check Items em- 
ployed by a client (step 3307). Then, the original screen 
is searched in the screen transition diagram 2105 (step 
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3308). Then, the component definition table 1901 Is 
searched for Che servlet name 1804 corresponding to 
the original screen to output to a form tag action attribute 
3404 (step 3309). Then, the form data specification 
2106 is read to generate the tew entered Into the form 
or names 3405 of pans such as burtons (step 3310). 

Then, the class specification 2113 Is read to output the 

attribute name of the Bean, ueing the syntax of ihe JSP, 
to the parameter of the parts orthe text in theform where 
appropriate (step 3311). Like in step 3311 , the method 

specification 2114 Is read to output il using the method 
of the Sean where appropriate (step 3312). A tag <jsp: 
getProperty> 3406 and a tag <%=%> 3407 are a JSP 
syntax like the tag <jsp:useBean> 3402. Finally, the file 
of the generated source code 3401 is stored in the 
source code data 2007, and then control exits from the 
processing for automatically generating the JSP source 
code (step 3313). 

piss] now, referring to Rg.3S, an explanation 16 giv- 
en to an example of a method for editing the source code 
of each component of the servlet, JSP, find Bean , in the 
code editing unit 2010. In Fig.35, reference numeral 
2801 designates an operation screen of the develop- 
ment support system according to this embodiment. In 
the region 2802 to the left of the screen, displayed are 
the contents of the component definition table 1 901 in 
a hierarchical structure. Here, suppose that the "Order 
confirm" 2804 Is selected and double-clicked. In this 
case, the editor will be opened on the region to the right 
of me screen to show the source code of each compo- 
nent for the "Order confirm" 2804. The servlet source 
code "ConflrmServlet.java" ia opened on on editor 
screen 3504. Likewise, the Bean source code B Cortflrm~ 

Boan.java" is oponod on tho oditor scroon 3603, whllo 
the JSP source code "confinn.jsp 1 ' is opened on the ed- 
itor screen 3504. Upon opening each source cede, the 
source code of each component to be edited is read 
from the source code data 2007, using the component 
definition table 1901. In addition, the "ConfirmServiet" 
2805 can be selected aloneto open the "Conf IrmServlet. 
java". This makes it possible forth© developerto Instan- 
taneously select and open the source code related to 
the screen to be developed, by selecting me screen 
name, allowing for retrieving or editing the source code. 
[01 40] *° dcooribed above, the present invention pro- 
vides the following effects. 

(1) Only a design document is described to create 
the component table of the name of each compo- 
nent This makes it possible to facilitate develop- 
ment of a system and alleviate the burden on de- 
velopers or programmers, thereby providing a re- 
duction in development time. 

(2) Relationship among the components of the serv- 
let, JSP, and Bean for each screen Is made clear 
and their respective roles are s parataly organized, 
thereby making it possible to develop each screen 
independently. 



(3) The source code of each component can be au- 
tomatically generated and thereby no special 
knowledge on Java Is required. This makes it pos- 
s ible to facilitate programming and thereby alleviate 

5 the burden on developers or programmers. Source 
cooes are automatlcairy generated In a standard- 
ized uniform fashion by the automatic code gener- 
ating unit. Thb facilitates maintenance and makea 
It possible to provide programs, the performance of 

10 which will not bo degraded but guaranteed, 

(4) Addition, extension, or modification of functions 
for upgrading the system would require only a new 
definition or addition of each component of the serv- 
let, JSP, and Bean, or easy identification of compo- 

1$ nents to be modified or those within the known 
range of modification. This makes it possible to Im- 
plement an extensible system. Furthermore, it can 
be safely said that what the development support 
system according to the present invention provides 

20 is the framework of a Web application system con- 
figured by the servlet, JSP, and Bean, 

(5) Upon development of a Web application system, 
each component can be defined by determining The 
GUI specification. This makes it possible to provide 

25 prototype or executable programs quickly, thereby 
allowing actual lest of the architecture of the system 
at earlier time. 

[0141] While there has been described what are at 
30 present considered lo be preferred embodiments of the 
present invention , it will be unde rstood that various mod- 
ifications may be made thereto, and it is intended that 
the appended claims cover all such modifications as fall 

within xho true spirit end coopo of the Invention . 
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Claims 

1 . A Web application development method for devoi- 
rs oping, on the Inter- and Intranet, a Web application 

system having servar-slde Java technologies such 
as a servlet, JSP, and JavaBeans component 
(Dean), wherein 

in accordance with a GUI specification provld- 

*s ec j by a deaign specification for eaid Web applica- 

tion system, a source filename of each component 
of the servlet, JSP, and Bean is defined correspond- 
ing to each screen image to develop the servlet, 
JSP. and Bean. 

so 

2. A Web application development method for devel- 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 
as a servlet, J5R and JavaBeans component 

ss (Bean), wherein 

In accordance with a GUI specification provid- 
ed by a design specification for said Web applica- 
tion system, a source filename of each component 
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of the servlet, JSP a and Bean is defined in a one-to- 
one relationship corresponding to each screen im- 
age to develop the servlet, JSP, and Bean. 

3. A method for developing a Web application accord- s 
ing to claim 1 or 2, wherein 

a source code of each component is automat- 
ically generated u&ingtho relationship between said 
screen and a source filename of each component 
of said sen/let, JSP. and Bean, and information of 10 
said design specification. 

4. A method for developing a Web application accord- 
ing to claim t or 2, wherein 

said Bean component is provided with all is 
pieces of information necessary for displaying an 
HTML page, and serves to carry out mapping Infor- 
mation of an HTML page and information to be re- 
trieved from a database. 

20 

5. A method for developing a Web application accord- 
ing to claim 3, wherein 

upon Generation of the source code of each 
component of said servlet, JSP, and Bean, 
a template list is displayed for each component to 
be generated, a template selected from the tem- 
plate list Is employed as a model, and a code is writ- 
ten to the model in accordance with said design 
specification to automatically generate a source 
code. 30 

6. A Wob application development method for devel- 
oping, on the Inter- and Intranet a Web application 
system having sorvorvtldo Java technologies such 

as a servlet, JSP, and JavaBeans component 39 
(Bean), comprising the steps of; 

reading a GUI specification provided by a de- 
sign specification to generate each component 
name of a servlei, JSP, and/or Bean corre- *o 
sponding to a screen name for each screen, 
selecting a template from a template list with 
respect to each component of a generated 
name, the template being a model of a source 
file of Che component, and <*s 
generating automatically a source code of the 
component by writing the code to said template 
in accordance with a design specification of the 
component 

50 

7. A method for developing a Web application accord- 
ing to claim 6, wherein 

said template list includes a superclass tem- 
plate, and the step of generating automatically said 
source code is to inherit said superclass to create 55 
said source code. 

8. A method for developing a Web application accord- 



ing to claim 6, wherein 

said step of generating a name of each com- 
ponent Is to generate a name of each component 
of a servlet, JSP, and/or Bean in a one-to-one rela- 
tionship with a screen name for said each screen. 

9. A method for developing a Web application accord- 
ing to any one of claime 1 to fi, wherein 

in a Web application system to be developed, 
the servlet serves to receive a request from a Web 
browser the Bean serves to perform processing in 
accordance with the request of the servlet to hold 
resulting data; and the JSP serves to retrieve the 
resulting data of the Bean to generate an HTML dis- 
played on the Web browser; thus each role of the 
servlet, JSP, and Bean being separated from each 
other. 

10. a program provided by a method for developing a 
Web application according to any one of claims 1 to 
9. 

11. A storage medium for storing a program provided 
by a method for developing a Web application ac- 
cording to any one of claims 1 to 9. 

12. A Web application development system for devel- 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 
as a servlet, JSP, and JavaBeans component 
(Bean), 

said system comprising means for developing 
the servlet, JSP, and Bean by defining a source 
filename of each component of tho son/lot, JSP, and 
Bean corresponding to each screen image, in ac- 
cordance with a GUI specification provided by a da- 
sign specification for said Web application system. 

13. A Web application development system for devel- 
oping, on the Inter- and intranet, a Web application 
system having server-side Java technologies such 
as a servlet, JSP, and JavaBeans component 
(Bean), 

said system comprising means for developing 
the eervlet, JSP, and Bean by defining a sou roc 
filename of each component of the servlet, JSP, and 
Bean in a one-to-one relationship corresponding to 
each screen image, in accordance with a GUI spec- 
ification provided by a design specification for said 
Web application system. 

14. A system for developing a Web application accord- 
ing to claim 12 or 13, further comprising 

means for automatically generating a source 
code of each component, using the relationship be- 
tween said screen and a source filename of each 
component of said servlei, JSP, and Bean, and In- 
formation of said design specification. 
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15. A system for developing a Web application accord- 
ing to claim 12 or 13, wherein 

said Bean component is provided with ail 
pieces of information necessary for displaying an 
HTML page, and serves to carry out mapping infor- 
mation of en HTML page and Information to De re- 
trieved from a database. 



accordance with the request of The servlet to hold 
resulting data; and the JSP serves to retrieve the 
resulting data of the Bean to generate an HTML dis- 
played on Che Web browser; thus each role of the 
5 servlet, JSP, and Bean being separated from each 
otner. 



16. A system for developing a Web application accord- 
ing to claim 1 4, furthar comprising to 

upon generation of the source code of each 
component of said servlet, JSP, and Bean, 
means for displaying a template list for each com- 
ponent to be generated, for employing a template 
selected from the template list as a model, and for « 
writing a code to the model in accordance with said 
design specification To automatically generate a 
source code. 



17. A Web application development system for devel- 2(7 
oping, on the Inter- end Intranet, a Web application 
system having server-side Java technologies such 
as a sen/let. JSP, find Java Beans component 
(Bean), comprising 

25 

means for reading a GUI specification provided 
by a design specif ication to generate each com- 
ponent name of a servlet, JSP, and/or Bean cor- 
responding to a screen name for each screen, 
means for selecting a template from a template so 
list with respect to each component of a gener- 
ated name, the template being « model of a 
source file of the component, and 

moans for gonorating automatically a couroa 
code of the component by writing the code to 36 
said template In accordance with a desian 
specification of the component. 

IB. A system for developing a Web application accord- 
ing to claim 17, wherein *° 

said template list Includes a superclass tem- 
plate, and tne means for generating automatically 
said source code are to Inherit said superclass to 
create said source code. 

1 9. A system f o r developing a Web application accord- 
ing to claim 17, wherein 

said means for generating a name of each 
component is to generate a name of each compo- 
nent or a servlet, JSP, and/or Bean in a one-to-one so 
relationship with a screen name for said each 
screen. 



20. A system for developing a Web application accord- 
ing To any one of claims 12 to 19, wherein 

in a Web application system to be developed, 
the servlet serves to receive a request from a Web 
browser; the Bean serves to perform processing in 
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Fig.4 Flowchart for generating a component table 
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Fig>5 Flowchart for automatically generating a source code 
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Fig.6 Flowchart for automatically generating a servlet source code 
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Fig.7 Generation of servlei source code 
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Fig.8 Source code of servlet superclass 
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Fig,9 Flowchart for automatically generating a JSP page source code 
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Fig. 10 Generation of a JSP page source code 
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Fig > 1 1 Flowchart for automatically generating a Bean source code 
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Fig. 12 Generating Bean source code 
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Fig. 13 Relationship between screen information find Bean 
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Fig.14 Overall configuration of a Web application system employing Servlet, 

JSP, and Bean 
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Fig. 15 Relationship between recipient and response components 
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Fig. 16 Definition 1 of recipient and response components 
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Fig. 18 Component definition table 
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Fig. 19 Component definition table 
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Fig-20 System configuration 
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^ri 
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5 
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Fig.22 Flowchart for generating component definition table 



Stan 



Read all screen information from the 
screen specification of the design <" 
information. ^ 



2 2 0 1 



Retrieve the screen name and ID froni 
the screen information. 



2202 



Add "Scrvlet* to the screen ID with the 
first character being written wtih its ^ 2 2 0 3 
upper-case letter lo form a servlet name. " 

i 



Add "Be&n M to the screen £D with the 
first character being written with its 
upper-case letter to form a Bean name. 



Supply an extension sign of ".jsp° to the 
screen ID to form a JSP filename. 



2 2 04 



22 0 5 



Add a set of the screen name, the screen 
ID, and each of the defined names to the 
component definition table. 



2 2 06 



2 2 0 7 




Store the component definition table in 
the component definition data. 



[ 



End 



2 2 0 8 
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Fig.23 Flowchart for automatically generating a source code 



Start 





Read (he component definition table. 




r 


r - — — > 




Retrieve the screen name from the 
component definition table. 



2 3 0 1 



2 3 0 2 



Retrieve (he name' of each component 
corresponding to the screen name. ^ <Z 



2 3 0 3 




Generate Bean source code. 



230 6 



Generate ISP source code. 



2 3 0 7 




End 
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Rg.24 Flowchart for automatically generating a servlet source code 



Generation of a servlet source code. 



Create a file with the soviet filename 
and with an extension sign of n .java\ 



240 1 



Read a servlet template list from the <" z 4 0 2 
template data. 



Select the corresponding template from 
the template list. „ S" 



Read the package specification t< 
generate package statement and import \< 

4- ~" 



Employ the servlet name as the class 
name to generate the class definition. 



T 



24 03 



2404 



2 4 0 5 



Generate the Bean name from the servlet 
as a Bean class to be used. 



Search the <u=roen tnwition diagram for 

ihc original screen. 



Read the form data specification of The 
original screen to retrieve and output a 



2 40 6 



2 407 



2408 



Read the session management 
specification. ^ S 



2409 



General* an item naj 


Be of the parameter 




retrieved from the ses 


UOOEL. 





Generate the parameter to be stored in 

the *e*5io»- 



24 11 



Read the error specification to output the 
contents of the processing upon £ a 4 1 2 



occurrence of an error. 



Generate the JSP name from the servlet 
as a JSP name to be used. 



Siorc die acjurtx, file of the generated 
servlet in the source code dad. 



J. 



24 13 



2 4 14 



End 
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Fig-25 Example of generating a servlet source code 



Servlet template 



2 10 1 



2 104 



_ _2 5 0 2 

// Package sentence < 

package [Package name of ineserYlei) ; 

// Import sentence 

import [Bean package name] .*; 

// Class definition 2 5 0 3 

public class t Servlet name) extends HtipServlet 

Jf 2 5 0 4 

public void service ( ^£ 2 5 0 5 
HupScrvldRcqucai fcqTHttpServJctResponsc rap ) 
throws ServletExcepdon, IOException 

// Generation of Bean ~» 
bean ° Bcans.insttntiatc ( gctCiassLoadcrO, [B«an name) ); 

fj Parameter retrieval and selling to Bean 
gctParamcter ( (Item name] ) 

^■2507 

// Retrieval from session 2 5 0 8 

season. gciAiiribuic ( [Item dome] ); 



( 



// Execution of BeaiL- 2 5 0 9 
bean.doTasx 



of Bean^I 

0i > 



U Storage in the session ^ — - 

setSessionAitribute ( [Item name] , [parameter] ); 

2 5 1 1 
// Processing upon error 




2 5 10 



^2512 
// Calling JSP ^> 

getRcqucstDi5patchcr ( [JSP name) ).forwsrd ( req y resp ); *4 
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Fig-26 Generation of a servlet source code 



Servlet template 



2 1 0 J 

IS 



^Z6 0 I 



//Package sentence ^2 5 0 2 

package [Package name of the servlet] ; — ^ 
//Import sentence ^25 0 3 

import [Bean package name) ; 

//Class definition ^ 2 504 ^-26 0 2 

public class [Servlet name] extends [Superclass name] 

// Setting of initiaJization S 2 6 0 3 
public void unit 0 throws ScrvIetExcepiion ( 

sctBcanNamc( [Bean name] ); 
setJspPage( [JSPname] >; 

) 

//Pre-processing ^ ^ 4 

public void befbreTask 0 throws ServletException ( 

// Retrieval Jrom session ^ 5 0 5 

sessioiugetAttribute ( [Item name] ); — ^ 

I 

^2 6 0 5 
// Post-processing ^> 
public void afterTask 0 throws ServlctException ( 

// Storage to session 2 6 10 

sessionsctAtiribute ( [item name) , [Parameter] ); ^ 

) 
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Fig.27 Servlet superclass code 



public abstract class BascScrvlet extends javax.servleUiup.HitpScrvlei 

private String jspname; // JSP name 703 

private String beanname; // Bean naine 

private BaseBean bean; // Bean object 2 7 0 4 

abstract public void ink 0 throws ServletException ; ^ 

public void service ( HcroServletRequest req, HttpScrvletRespoiise resp ) 
^vo ws ServletException, IOException 2 7 0 S 

try ( 

create 0; f/ Bean generation 

beforcTask 0; H Pre-processing 

doT«k 0; ;/ Bean execution 

afterTask 0; '/ Post-processing 

canispO; //JSP call 

) catch (Exception e) { 

error 0> ff Error processing 

I ^27 06 

private void create Otfavws ServletException { 

// Processing for generaungfr^ 0 7 

protected void beforcTask 0 throws ServletExceptiGn I 

// To be implemented in subclass if necessary 

} <T 2 7 0 8 

private void dolask Otnrows ServletException J 

U Processing for executing Bean 2 7 0 9 

} 

protected void afterTask 0 throws ServletException ( 
// Tb be implemented in subclass if ncrcssary^ ^ 

private void cnlUsp 0 throws ServletException ( 

// Processing for calling JSP 2 7X1 

private void error 0 throws ServletException { 

// Enor processing ^-27 l 2 

void serJspPage C String name ) ( this jspname = name: \ 
Siring geUspPage 0 i ****** jspcame; ) 
void setBeanName ( String name) | this.beannarne * name; ) 
String getBeanName 0 \ return beanname; ) 

I 
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2801 



Fig.28 Image of template selection 

.2 802 




S-TOp —28 0 3 

1 J— Menu 

I 5— New order^, 2 8 0 4 

Order OMrfbTB 2 8 0 5 
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Fig.29 Image of template selection 
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Fig. 30 Flowchart for automatically generating a Bean source code 



Generation of a Bean source 

I 



Create a file with the Bean filename 
employed as the filename and with an kT 
extension sign of ".java". 



Read a Bean template list from 
the template data. 



Select the corresponding template 
from the template list. ^ S 



Read the package specification to 
generate package statement. 



Employ the Bean name aa the class 
name to generate the clasa _ ^ 
declaration. 



Search and chen generate the Bean 
superclass name from the class 
specification. 



3 00 1 



3 00 2 



3003 



3004 



300 5 



3 0 0 6 



Generate the processing for 
executing the Bean from ihe ^-3 007 
sequence diagram. 



Search the screen transition 
diagram for the original screen. ^ *> 

I — 



Read the form data specification 
of the original screen to retrieve-}^ 
and output a parameter. 

1 



300 $ 



300 9 



Read checlc items to generate the 
check processing of the parameter. 



Generate the declaration of the < - 

attribute from the class specification, -4- > 



dec; 

e cL 

I 

eral 
and 



Define and generate the setting of 
the attribute and the retrieved J? 
method. 



Read the method specification and 
generate methods other than the_ 5T 
attribute setting and retrieval 



Store the generated Bean source 
file in the source code data. IS* 



3 0 10 



3 0 11 



3 0 12 



3 0 13 



30 14 



End 
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Fig.31 Example of generating a Bean source code 




// Package sentence^* 
package [Package name of the Be 



_. 3 l 0 3 

// Class definition 1 
public da» [Bean name] extends (Parent class of Bean) 



( 



// Bean processing^* 3 10 4 
public void doTask () throws BeanExcepiion 



( 



if ( check 0 false) I 
throw new BascServlet 0; 

' - 3 1 0 5 



f) Processing ■< 



J 



// Check for ] 
protected boolean chcckO 
\ 



// Parameter retrieval J> 
getParameter ( (Item name) ); 



3 10 6 
3 10 7 



// Anribuie declaration 3110 



// Retrieval of attribute and 



definition of setting method 
<4 



// Definition of other methods 

) ^3 1 1 1 
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Component definition 
table 



Class specification 
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transition diagram 



Form 

data specification 
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2 113 
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Method specification 
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Fig.32 Relationship between screen information and Bean 
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204 



ConfirmBean 



User 
Dale 

1 Date of delivery 
1 Each name [4] 
• Each unit price [4] 

■ Sum 

■ Number of sets 



4B 



EP 1 139 216 A2 



Fig33 Flowchart for automatically generating a JSP source code 



Generation of a JSP source code. 



Create a file with the JSP filename 
employed as the filename. 



3 3 0 1 



Read the HTML file of the screen 
image. 



3 3 0 2 



Generate the contents of the 
HTML file. 



3 3 0 3 



Read a JSP template list from the 3304 
template data. 



Select the corresponding template 3305 
from the template list <T 



Generate the Bean name as a 
class to be used in JSP. 



3 3 0 6 



Read the event specification to 
generate a script definition. 



3 3 0 7 



Search the screen transition 
diagram for the linked screen. 



1 



3 3 0 8 



Search the component table for 
and generate the soviet name of 
the linked screen. 



3 3 0 9 



Read the form data specification to 
generate the name of form parts. 



3 S 1 0 



Read the class specification to output 
the attribute name of the Bean where 
appropriate. 

1 — 



Read the method specification to 
output the method of the Bean where 
appropriate. 

+ 



3 3)1 



3 3 12 



Store the generated JSP source 
file in the source code data. 



3 3 13 



End 
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Fig.34 Example of generating a JSP source code 
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JSP template 
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Screen image 



3 4 0 1 



<%@ page contcntTypc^icxi/html - %> 



<jsp:uscBean id* w obj- type- [Bean name] 
</jsp:u5cBcan> *^ 



"3 40 2 



^HTML> 
<HEAD> 

<SCRIPT> _ 3 4 0 3 

<!- J> 
//Script definition 



//-> 

</SCKCPT> 

</HEAD> 

<BODY> 




<FORM action* [Destination service name] > 



< INPUT name- [Item name]^ - 
X 34 0 5 



<jsp'.gctPropcrty 



<%"id. [Method] f> 

3407 

</F0RM> 



</B0DY> 
</HTML> 



3 4 0 6 

obj" property- (Attribute name) /> 




19 0 1 



Component definition 
table 



Screen transition diagram 
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Event specification 
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Form 

data specification 
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2 6 0 1 



Fig.35 linage of editing source codes 

x 2802 >3S0 1 



Orders 



"JSP 
I — confirrngsp 
1 3- Order completed 
E 3- Existing order list 

E«iHb>l order contents eonftm 

E 5- Order change 
Order cancel 




3 5 0 2 



3 5 0 3 



3 5 04 



51 



